We bump our `vss-client` dependency to include the changes to the
`StorableBuilder` interface.

Previously, we the `vss-client` didn't allow to set `ChaCha20Poly1305RFC`'s `aad` field,
which had the `tag` not commit to any particular key. This would allow a
malicious VSS provider to substitute blobs stored under a different key
without the client noticing.

Here, we now set the `aad` field to the key under which the `Storable`
will be stored, ensuring that the retrieved data was originally stored
under the key we expected.

We also account for `StorableBuilder` now taking `data_decryption_key`
by reference on `build`/`deconstruct`.

We previously attempted to drop the internal runtime from `VssStore`,
resulting into blocking behavior. While we recently made changes that
improved our situation (having VSS CI pass again pretty reliably), we
just ran into yet another case where the VSS CI hung (cf.
https://github.com/lightningdevkit/vss-server/actions/runs/19023212819/job/54322173817?pr=59).

Here we attempt to restore even more of the original pre-
ab3d78d / lightningdevkit#623 behavior to get rid of
the reappearing blocking behavior, i.e., only use the internal runtime
in `VssStore`.

As LDK currently will still panic and crash if we'd ever fail a `write`
operation, we here considerably bump the defaults set in `VssClient` to
at least make this less likely. Longer term, we still hope to mitigate
the issue by moving to the async-persist flow.